Systems and methods involving features of sales force processing and/or productivity

ABSTRACT

Systems and methods are disclosed associated with classifying, processing and interpreting information based on the aggregation and/or analysis of fact-based data events. Some implementations include associated notifications, reports and/or dispute resolution mechanisms.

CROSS REFERENCE TO RELATED APPLICATION DATA

This is a continuation of application Ser. No. 13/905,115, filed May 29,2013, published as US2014/0046711A1, now patent Ser. No. ______, whichclaims benefit/priority of U.S. provisional patent application No.61/652,830 filed 29 May 2012, which are incorporated herein by referencein entirety.

BACKGROUND Field

Aspects of the present inventions relate to “Sales Force Automation” or“Sales Force Management” systems (hereinafter collectively referred toas “SFA”) and other systems that rely on data entry by users, dataquality enforcement and facilitation for those systems, and both BigData Analytics and Business Analytics, and, more particularly, tosystems and methods for providing user-centric tools that help companiesto facilitate and enforce both user software adoption and data qualityin user data entries; automate data collection tasks and distill largevolumes of relevant data from telecom networks and devices, datanetworks and devices, billing systems, mobile and other computing andcommunications devices; shorten the time needed to make that data usefuland available; provide real-time access to data while making that datamore user-centric and consumable by business stakeholders; and translatelarge volumes of transactional data into business insight to drivebusiness decision-making.

Aspects of the present inventions utilize a data-driven approach tosolving the core data quality issues for systems that collectinformation from users via data entry, such as Customer relationshipManagement and Sales Force Automation systems, and enhances thosesystems with actionable insight derived from objective data sources andthe data quality facilitation and enforcement mechanisms describedherein.

Description of Related Information

Too much data is a massive analysis issue. The volume, variety andvelocity of newly available data sources challenge IT leaders to extractactionable insight from those sources while the veracity of related userdata entries often complicates those challenges. As such, some of thesolutions/innovations herein are designed to make sense of Big Data andother data sources to find patterns that help organizations bettermanage their data quality and employees, and gain new insights thatenable them to make better financial projections and better manage theirsales processes.

Further, drawbacks of current “Sales Force Automation” or “Sales ForceManagement” systems (hereinafter referred to as “SFA” and/or “SFM”)include or involve aspects of failing to effectively address one or moreof 3 core issues adoption, data integrity and/or productivity. Forexample, many such systems suffer with respect to adoption in beingunable to address issues of salespeople failing to enter relevant datainto the system on a timely basis or at all. Further, many sufferdrawbacks with respect to data integrity, such as issues relating tosales pipeline projections that are often overly optimistic. Finally,such systems have drawbacks with respect to accurate productivitymeasures, such as when level(s) of productive activity may not bode wellfor future sales results in future quarters, but management may not havea reliability check on the level of sales prospecting and sales processactivity that may be lacking.

In sum, there is a need for systems and methods that may adequatelyaddress these and other drawbacks.

OVERVIEW OF SOME ASPECTS

Aspects of the innovations herein may involve proprietary systems,methods and to answer these new questions in the areas of sales forcemanagement, sales forecast analysis, workforce policy adherence andtechnology adoption facilitation and enforcement. Further, salesproductivity solutions/innovations herein may leverage both new andexisting data streams to look for patterns within the business thatcorrelate to success or failure in the context of the organization'ssales forecasts and objectives. Implementations herein may alsodynamically models way to address correlations to failure—in order tosuggest changes to process and individual activities and therebymeaningfully and positively affect outcomes. This “seek, model andadapt” approach is designed to empower companies to leveragesystem-based pattern-detection in both their strategic and tacticaldecision-making, in all phases of the sales and sales-forecastingprocess.

It is to be understood that both the foregoing general description andthe following detailed description are exemplary and explanatory onlyand are not restrictive of the inventions, as described. Furtherfeatures and/or variations may be provided in addition to those setforth herein. For example, the present invention may be directed tovarious combinations and subcombinations of the disclosed featuresand/or combinations and subcombinations of several further featuresdisclosed below in the detailed description.

DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which constitute a part of thisspecification, illustrate various implementations and aspects of theinnovations herein and, together with the description, help illustratethe principles of the present inventions. In the drawings:

FIG. 1A is a diagram of an illustrative web or network-basedimplementations consistent with certain aspects related to theinnovations herein.

FIG. 1B is a diagram of an data aggregation implementations consistentwith certain aspects related to the innovations herein.

FIGS. 2A-2B are flowcharts of illustrative mobile phone captureprocessing consistent with certain aspects related to the innovationsherein.

FIGS. 3A-3B are flowcharts of illustrative PBX phone call captureprocessing consistent with certain aspects related to the innovationsherein.

FIGS. 4A-4B are flowcharts of illustrative phone call and SMS captureprocessing from carriers consistent with certain aspects related to theinnovations herein.

FIGS. 5A-5C are flowcharts of illustrative geo location captureprocessing from mobile devices consistent with certain aspects relatedto the innovations herein.

FIGS. 6A-6C are flowcharts of illustrative geo location captureprocessing from phone carriers consistent with certain aspects relatedto the innovations herein.

FIG. 7 is a flowchart of illustrative user4 classification processingconsistent with certain aspects related to the innovations herein.

FIGS. 8A-8B are illustrative user interfaces showing exemplaryclassification processing features consistent with certain aspectsrelated to the innovations herein.

FIGS. 9A-9C are illustrative user interfaces showing exemplaryclassification processing features consistent with certain aspectsrelated to the innovations herein.

FIGS. 10A-10B are illustrative user interfaces showing exemplaryclassification processing features consistent with certain aspectsrelated to the innovations herein.

FIGS. 11A-11D are flowcharts and illustrative user interfaceimplementations showing facilitation processing consistent with certainaspects related to the innovations herein.

FIGS. 12A-12E are flowcharts and illustrative user interfaceimplementations showing enforcement processing consistent with certainaspects related to the innovations herein.

FIGS. 13A-13H are flowcharts and illustrative user interfaceimplementations showing integrity resolution processing consistent withcertain aspects related to the innovations herein.

FIGS. 14A-14C are flowcharts and illustrative user interfaces ofillustrative dispute resolution processing and notification managementprocessing consistent with certain aspects related to the innovationsherein.

FIG. 15 is a flowchart of illustrative privacy management processingconsistent with certain aspects related to the innovations herein.

FIGS. 16A-16F are flowcharts and illustrative user interfaceimplementations showing time allocation and productivity analysisprocessing consistent with certain aspects related to the innovationsherein.

FIG. 17 is a flowchart of an illustrative pipeline filter processconsistent with certain aspects related to the innovations herein.

DETAILED DESCRIPTION OF ILLUSTRATIVE IMPLEMENTATIONS

Reference will now be made in detail to the inventions herein, examplesof which are illustrated in the accompanying drawings. Theimplementations set forth in the following description do not representall implementations consistent with the present inventions. Instead,they are merely some examples consistent with certain aspects related tothe present innovations. Wherever possible, the same reference numberswill be used throughout the drawings to refer to the same or like parts.

Certain systems and methods herein relate to innovations characterizedherein as involving aspects as described below. Various presentinnovations relate to the enforcement and facilitation of data entriesin software systems that require systemic and methodical data entry bysoftware users in order for such software systems to be effective. Suchsoftware systems include but are not limited to sales force automationand sales force management systems and encompass any system wherein useradoption and the honesty and integrity of user-entered data meaningfullyimpacts on system effectiveness (such as Business Intelligence,Analytics and Financial Services software that requires compliance).

Most software systems for managing employee efforts, activities andpolicy/process compliance, such as Sales Force Automation (“SFA”)systems (also known as “Sales Force Management”), fundamentally rely oninputs being methodically entered into the system by sales team membersas well as on the integrity of those team members. As such, the datagenerated by such systems has generally been incomplete (user adoptionissue) and plagued by inaccurate information (user integrity issue).

The innovations contained herein include the ability to aggregate,measure, track and cross reference each person's “event data stream”:including electronic calendar entries, previous CRM and Sales ForceAutomation system data entries, records of PBX (circuit-switched andpacket-switched, directly or indirectly via Presence Manager or othersystems that can provide such records) and mobile phone calls made toprospects and customers, emails, SMS messages, chat messages, faxinformation obtained from fax server, desktop fax software program orfrom the Call Detail Records (“CDR”) of fax lines, credit cardtransaction data, Wifi and geo-location data (related to site visits andoff-site meetings and other location-relevant reporting)—and to identifythe points at which follow-on data entries are ordinarily required.

As such, the innovations contained herein include new approaches to thedetermination that an event has occurred that requires follow-on humandata-entry; as well as a new classification approach to processing rawdata to improve the quality of that data and prepare it for analysis.Systems and methods herein may also include processes for enforcing useradoption compliance. Here, for example, implementations may recognizeexternal events that require human data entry, provide one or moremechanisms for displaying and classifying “unprocessed” events (e.g.,raw data without context, etc.), and provide escalation thresholds basedon elapsed time for processing events. Further, such escalationthresholds may vary as a function of various factors such as event type,opportunity type/size, customer value, etc and/or may include thecontext of the relevant person's schedule and ability to respond.

Innovations contained herein also include processes for managing userintegrity in data entry; by cross-referencing machine data and otherdata external to the software system with user-entered data in order toidentify factual discrepancies that can be classified as “Integrityevents;” to provide managers with insight about events about whichsalespeople may be unintentionally misleading themselves orintentionally misleading the manager or company.

Innovations herein also include processes for providing automatedwarnings (such as those customizable by managers) to system users and anescalation process to a manager (via email, SMS or rolling data feed)based on customizable thresholds—as well as a resolution process fordealing with missing data (e.g. adoption issues) and data discrepancies(e.g. integrity issues). Present innovations may also include historicalreports and/or the ability to define policy profiles and apply differentpolicy profiles to different employees and different classes of salesopportunities and/or be configured for exception handling, such ashandling discrepancies between objective data and user-reported data aredisregarded if they fail to meet a customizable discrepancy threshold.Here, for example, a discrepancy of less than X minutes on the reportedduration of a meeting or a call may be disregarded.

The innovations contained herein also include methods for thefacilitation of user adoption of software systems—including (i)recognizing the occurrence of relevant events and providing employeeswith automated reminders to manually enter the appropriate data into thesoftware system; and/or (ii) by reducing time commitment ordinarilyassociated with SFA data entries by auto-populating fields in the userinterface with data obtained from alternate sources.

The innovations contained herein also include productivity andtime-allocation tracking and analysis by through the use of machine dataand other data sources. Managers and salespeople themselves can viewtheir own productivity reports to gain insight on their time allocationvia a variety of factors, as set forth in more detail below.

The innovations contained herein also include a new and differentiatedapproach to sales pipeline forecasting that applies “data patternmatching and modeling” analysis to sales opportunities in a salespipeline: to identify those opportunities who's external data attributesseem to correlate to failure rather than success. For example, pipelineitems will be flagged for managers if the opportunity has had fewerexternal data ‘events’ (phone calls, email exchanges, site visits, etc.)of sufficient duration than the data model suggests is correlative witha successful sales outcome, taking variables such as seasonality intoaccount. This data model is dynamically updated as new sales take place.As a result, the analysis becomes more accurate the longer the solutionis in place. This analysis is run using objective data sources (theaggregated personal data streams described above) filtered to providedata about specific sales opportunities—without the context of employeeopinions (as reflected in their data entries) and without reference totheir self-report characterizations of the relevant events. Thismodeling component provide for correlation analysis of employeeprojections with dynamically updated, data-driven success models—inorder to assist managers to more accurately assess pipeline quality,better forecast sales revenue and offer direction for employee trainingand mentoring.

The innovations contained herein and their pattern-based methodologiesgo beyond simple business intelligence derived from user inputs; toanalyze a diverse range of technologies across a diverse set ofdisciplines and join together a variety of complex new and existing datastreams into a single framework for technology adoption analytics,factual integrity analytics and data quality enforcement, sales processand sales productivity management analytics (which includes salesterritory management analytics) and sales forecast opportunity analysis.

Today, many “data processing events” are either undetected or remainunused and therefore unavailable to the legacy systems that couldbenefit from the data and insight they can bring. These events can bedetected, captured, represented electronically and housed in adatabase—but the true challenge for innovators in the area of eventprocessing is to make good use of this data. That is the challenge thatdrives the innovations contained herein, where both new and existing“event data streams” are aggregated, cross-referenced, correlated andsynthesized within to provide meaningful business insight that canempower better business decision-making, improve the performance ofexisting software investments (such as SFA's) and positively impact onbusiness outcomes, revenue and the ability to process and understand theconsequences of business activities as they happen.

FIG. 1A is a diagram of an illustrative web or network-basedimplementations consistent with certain aspects related to theinnovations herein. While the description of FIG. 1A shows variouselements, the components of the system can be implemented through anysuitable unitary or distributed combination of hardware, software and/orfirmware. Referring to FIG. 1A, the illustrated system may include atleast one Sales Force Processing (“SFP”) server and/or component 160,users at access devices 121 (e.g., one or more of access devices121A-121D), one or more connectivity components 125A/125B, as well aspossibly other unitary, connected, interconnected or distributedprocessing entities or components such as network management components,a first sales force automation (“SFA”) server/component 130, a secondSFA server/component 140, a third (or more) SFA server/component 150,other third party servers or components 155, and/or additional providers180 such as information providers, all connected over a network 170 suchas a Wide Area Network, a Local Area Network, or a combination includingthe Internet. The Sales Force Processing server/component 160 may, insome implementations, include one or more management components 170,such as optionally an adoption management component 172, an integritymanagement component 174 and/or a productivity management component 176.Further, the Sales Force Processing server/component 160 may, in someimplementations, be the web-based platform for handling and/orperforming processing regarding various sales force management features,functionality and/or innovations herein.

Implementations herein may include various management components 170that perform methods for managing complete and accurate data forbusiness analysis. Such implementations may accomplish this via adoptionmanagement, integrity management and productivity management. Furtherimplementations may be aided by data quality and process enforcement aswell as facilitation of machine data. User adoption systems may beconfigured with features that recognize the occurrence of relevantevents and providing employees with automated reminders to manuallyenter the appropriate data into the software system; and by reducingtime commitment ordinarily associated with Sales Force Automation “SFA”data entries by auto-populating fields in the user interface with dataobtained from alternate sources.

Systems and methods herein may include or involve a variety ofprocessing components and mechanisms for performing the innovationshere, such as:

Data Stream Aggregation Mechanisms: Aggregation processes runcontinuously across diverse devices and networks and comprise applicabledata regarding all forms of network, voice and electronic datacommunications together with geo-location data and electronic records(such as electronic calendar data, etc.), and such records include butnot limited to origination, destination/termination, user and durationattributes.

Classification Mechanisms: classification interface(s) and processes areprovided that displays each user's relevant raw data as unclassifiedevents and provides a means of classifying those events with a series ofdefault or custom classifications based on the type of work performed ifthe event is work-related or, alternatively, with a series of default orcustom classifications if the event is not work-related.

Facilitation Mechanisms: The innovations contained herein also includemethods for the facilitation of user adoption of softwaresystems—including (i) recognizing the occurrence of relevant events andproviding employees with automated reminders to manually enter theappropriate follow-on data into the software system; and (ii) byreducing time commitment ordinarily associated with user interface dataentries by auto-populating fields in the user interface with dataobtained from alternate sources.

Enforcement Mechanisms: The manager sets duration interval thresholdsthat define how long a raw data event can remain unprocessed/pending(“pending classification”) before automated, customizable reminders aresent out (“user adoption enforcement”); and configures the escalationprocess so that a notification is sent to or displayed for the managerwhen the reminders have not led the user to classify the data on timeand also provides access to historical reports and the ability to definepolicy profiles and apply different policy profiles to differentemployees and different classes of sales opportunities andadministrative tasks.

Integrity Incident Identification Mechanisms: The innovations containedherein also include processes for managing user integrity in data entry;by cross-referencing data obtained in the data aggregation process withuser-entered data in order to identify factual discrepancies that can beclassified as “Integrity incidents”—incidents which may be escalated ordisregarded depending on whether they meet a customizable discrepancythreshold (for example, a manager may specify that a discrepancy of lessthan X % on the reported duration of an event such as a live meetingshould be disregarded, whereas a discrepancy of greater than X % shouldbe escalated).

Dispute Resolution Mechanisms: A dispute resolution and retroactiveexception approval process begins when the time-limit threshold has beentriggered and the manager has been alerted that a user has failed toclassify an unprocessed/pending event within the specified time intervalor when an integrity incident has been flagged by the system andreported to the manager; at which time the user is provided theopportunity to append an explanation to the notification in order toadvise their manager(s) of extenuating circumstances so that the managercan opt to treat the event as ‘compliant’ for reporting purposes—or not(this ‘adjusted data’ can be used for reporting as asupplement/replacement for the purely factual data depending on thecontext in which the data is being used and whether that context needsto incorporate extenuating circumstances).

Notification Management Mechanisms—The innovations contained herein alsoinclude configuration mechanisms to limit volume of notifications to amanageable volume and to suite the particular management style of theindividual manager; wherein a manager can limit user adoptionenforcement and integrity incident notifications with configuration thatalters what is escalated based on variables that include but are notlimited to named employee, named prospect/customer, event type, size ofcurrent opportunity, dollar value of potential follow-on opportunities,size of prospect/repeat customer, dollar value of historical businesscustomer has done with company to date, or by a variation thresholdpercentage (for example, do not report if discrepancy in data entryabout an event's duration is less than X minutes)

Privacy Management Mechanisms: Various privacy management mechanisms maybe provided. For example, users can turn off “location services” ontheir mobile devices to disable geo-location tracking, which will becharacterized as an integrity incident if such disablement takes placeduring work hours that has not been designated as a personal day orapproved block of personal time or time in an environment where signalaccess is unavailable; with the result that a notification in suchcircumstances will be sent to the manager after a pre-set time-intervalthreshold (which will specify how long an integrity incident must lastbefore it is reported in order to avoid creating events for time spentin parking garages, elevators, tunnels and other environments withoutsignal access).

Time Allocation and Productivity Analysis Mechanisms: The innovationscontained herein also include productivity and time-allocation tracking,analysis and data modeling mechanisms for the purpose ofself-assessment, comparative assessment, manager employee assessment,mentoring and territory analysis (by providing managers with data andanalysis to distinguish between both ‘order takers’ who make littleeffort to obtain new business yet still make quota in territories thatshould be split and salespeople who intentionally slow down their salesactivities to push out sales opportunities to stay below their salesquota in order to avoid a territory split—and salespeople who makeheroic efforts to meet their sales quota in territories that shouldlogically not be split); with such productivity and time allocationmechanisms leveraging and relying on the data stream aggregationmechanisms described in step 1 in order to (i) enable managers, teamsand individual users to view their own productivity reports and analyzetheir time allocation by activity type, account value, qualified versusunqualified leads, sales funnel stage (including: prospecting, newopportunities, initial communications, fact finding, solutiondevelopment, solution proposal, solution evaluation, negotiation,purchase order, etc.), time allocation on sales versus non sales(internal) activities, as well as the speed and quality of theirfollow-up—to both challenge their subjective perceptions, self-assesstheir efforts, mentor others and gain insight on what adjustments can bemade to improve performance (to this end, salespeople will have theopportunity to contrast and compare their time allocation to that ofanother salesperson and/or a composite of the top X % of salespeopleand/or to the team in general).

Forecast Analysis Mechanisms: The innovations contained herein alsoinclude a dynamically-updated data pattern matching and modelinganalysis that relies on the aggregated personal data streams describedabove (filtered to provide data about specific sales opportunities)which correlates the spectrum of historical aggregated data streamevents to historically successful sales outcomes (factoring in businessseasonality) in order to identify those current opportunities in thesales pipeline whose external data attributes appear to correlate moreto failure than success—with a data model that is dynamically updated asnew sales take place so that the analysis becomes more accurate thelonger the solution is in place.

Implementations herein also include productivity and time-allocationtracking and analysis by through the use of machine data and other datasources. Such implementations may include integrity and productivitymanagement features. Managers and salespeople themselves can view theirown productivity reports to gain insight on their time allocation byactivity type (including time spent on internal and external activitiesas well as business related and non-business related activities,including personal calls), total account or individual sale value,qualified versus unqualified leads, sales funnel stage (including:prospecting, new opportunities, initial communications, fact finding,solution development, solution proposal, solution evaluation,negotiation, purchase order, etc.), time allocation on sales versus nonsales (internal) activities, as well as the speed and quality of theirfollow-up. Allowing employees to see this productivity-relatedinformation allows them to both challenge their subjective perceptionsto self-assess their efforts and gain insight on what adjustments can bemade to improve performance. To this end, salespeople will have theopportunity to contrast and compare their time allocation to that ofanother salesperson and/or a composite of the top X % of salespeopleand/or to the team in general. Over time, productivity modeling enablesteam members to process how changes in their own productive behaviorscan impact on their sales performance. For the manager, productivitybecomes a dashboard metric with associated alarms and configurablereports. The modeling component provides managers with valuable insightson where productive efforts should be focused in the context of specificproduct lines while also providing the business insight required formentoring and assessing sales staff. Historical productivity data isalso used for productivity data pattern-matching and modeling to createtime allocation/optimization success models. Productivity analysis alsoprovides insight for sales territory management by enabling managers todistinguish between ‘order takers’ who make little effort to obtain newbusiness and salespeople who make heroic efforts to meet their salesquota. This distinction provides meaningful insight on when salesterritories should be split and arguably provides a superior metric tothe most common practice of splitting sales territories when they reachsales quota targets.

FIG. 1B is a block diagram of the aggregated data stream 195 thataggregates data of a user/employee from a plurality of remote datastreams, e.g., over various wireless and wired communication networks.The data streams may include desktop/laptop records, presence managerrecords, CRM/SFA records, data network records, credit card records,electronic calendar records, email records, chat records, SMS records,fax server and fax line records, PBX records, mobile call records,mobile device records, geo-location records and other records. The datafrom the aggregate data stream may be stored in a server, database, etc.

FIGS. 2A-2B are flowcharts of illustrative mobile phone captureprocessing consistent with certain aspects related to the innovationsherein. Referring to FIG. 2A, an illustrative process of capturing amobile phone call and/or SMS is shown. In a few optional initial steps,a salesperson may log into the Sales Force Automation SFA server from amobile device, at 202, and/or configuration settings may be loaded fromthe backend, at 204. Configuration settings may then be loaded from amobile application (“app”), at 206. The app may then be registered, at208, to listen to call events such as incoming calls, outgoing calls,declined calls, missed calls, incoming SMS, outgoing SMS, etc. At 210,the mobile app receives notification of a new call event 210, at whichpoint media tracking may then be enabled or not enabled, at 214. Ifmedia tracking is not enabled, the process returns to 210 to awaitreceipt of another notification of a new call event. If, at 214, mediatracking is enabled, the process then creates a call detail record(CDR), at 216, which may include data such as date, call type, name,number and/or user ID. Next, the call detail record is sent to thebackend server, at 218, e.g., to a SFA server, a CRM server, or thelike.

According to various implementations herein, call event notificationsmay be received in real-time from the underlying mobile OS or the nativecall application of the device. Call event notifications may also bereceived from third party application(s) installed in the mobile phone(Lync, Skype, Line2, etc.). Moreover, implementations may also beconfigured such that the Call Log may be downloaded from the mobile tothe desktop and processed as a batch file. Here, for example, iTunes maybe used to download the call logs to a desktop. Then, the same processdescribed above might be applied to create all the CDR and send them tothe backend server to be processed.

Further, in some embodiments, a verification step may then be performedto confirm that the call detail record was sent successfully 220. If so,the process may again return to 210 to await receipt of anothernotification of a new call event. If the send is not successful, a copyof the call detail record is saved in connection with the mobile device,at 224, such as in the mobile device app database. Then, a routineattempting to again send the call detail record, or wait and re-send it,is performed, at 226, 228 and 232. Once the re-send is successful, theprocess proceeds to a step of deleting the copy of the CDR from themobile app database, at 234, and again returning to 210 to await receiptof another notification of a new call event. The verification stepdescribed above might be performed either synchronously orasynchronously.

Referring to FIG. 2B, an illustrative process of data treatment andstorage into the database by the backend is shown. The backend receivesthe CDR sent by the mobile app (cf. FIG. 2A), at 232. At which point,the backend verifies that the date and time of the CDR are withinbusiness hours, at 242. If not, the CDR will not be processed, at 244.If within business hours, then the process verifies that the Privacymode is not enabled, at 246. If enabled, the CDR will not be processed,at 248. If not enabled, the process stores the CDR in a preliminarydatabase table, at 252, at which point a trigger is sent indicating anew record has been added and ready for processing, at 254. Additionalattributes are assigned to the record if certain predefined criteria aremet, at 256. A partial list of these attributes can include: Short call,Personal call, internal call, etc. The process cross-references the SFAdatabase to retrieve any existing SFA entity records that might beassociated with the CDR, such as Contact, Account, Lead and Opportunity,and adds the results to the record, at 258. The record is now ready tobe added to the database table of processed records and marked asPending, at 260. The record is now viewable on the desktop applicationas well as the mobile application, 262.

FIGS. 3A-3B are flowcharts of illustrative PBX phone call captureprocessing consistent with certain aspects related to the innovationsherein. Referring to FIG. 3A, an illustrative process of capturing phonecall data from phone systems is shown. In a few optional initial steps,a phone system connector may log into the Sales Force Automation SFAserver as an administrator, at 302, and/or configuration settings may beloaded from the backend, at 304. The phone system connector isconfigured to log into the phone system and register to listen to callevents such as incoming calls, outgoing calls, declined calls, missedcalls, etc., at 306. The phone system connector can launch a query tothe phone system to retrieve all the Call Detail Records not receivedsince last connection, at 308. The retrieved CDRs can be added to thequeue of new call events to be processed. The phone system connector canreceive notification of a new call event for a specific user, at 310, atwhich point the phone system connector can verify if the media trackingis enabled or not enabled, at 314. If media tracking is not enabled, theprocess may return to 310 to await receipt of another notification of anew call event. If, at 314, media tracking is enabled, the process canthen create a call detail record (CDR), at 316, which may include datasuch as date, call type, name, number and/or user ID. Next, the calldetail record is sent to the backend server, at 318, e.g., to a SFAserver, a CRM server, or the like.

According to various implementations herein, the process described mayapply to any local phone call system (a short list of these includesTraditional PBX, virtual PBX, Key system, Call managers, Presencemanagers, Softswitch). Further, in some embodiments, a verification stepmay then be performed to confirm that the call detail record was sentsuccessfully 320. If so, the process may again return to 310 to awaitreceipt of another notification of a new call event. If the send is notsuccessful, a copy of the call detail record may be saved in connectionwith the phone system, at 324, such as in the phone system connectorlocal database. Then, a routine attempting to again send the call detailrecord, or wait and re-send it, may be performed, at 326, 328 and 332.If the re-send is successful, the process can proceed to a step ofdeleting the copy of the CDR from the phone system connector database,at 334, and again returning to 310 to await receipt of anothernotification of a new call event. The verification step described abovemight be performed either synchronously or asynchronously.

Referring to FIG. 3B, an illustrative process of data treatment andstorage into the database by the backend is shown. The backend canreceive the CDR sent by the phone system connector (cf. FIG. 3A), at340. At which point, the backend may verify that the date and time ofthe CDR are within business hours, at 342. If not, the CDR will not beprocessed, at 344. If within business hours, then the process can verifythat the Privacy mode is not enabled, at 346. If enabled, the CDR willnot be processed, at 348. If not enabled, the process can store the CDRin a preliminary database table, at 352, at which point a trigger may besent indicating a new record has been added and ready for processing, at354. Additional attributes can be assigned to the record if certainpredefined criteria are met, at 356. A partial list of these attributesincludes, but is not limited to: Short call, Personal call, internalcall, etc. The process can cross-reference the SFA database to retrieveany existing SFA entity records that might be associated with the CDRsuch as Contact, Account, Lead and Opportunity, and can add the resultsto the record, at 358. The record is now ready to be added to theRecorded Events database marked as Pending, at 360. The record is nowviewable on the desktop application as well as the mobile application,362.

FIGS. 4A-4B are flowcharts of illustrative phone call and SMS captureprocessing from phone carriers consistent with certain aspects relatedto the innovations herein. Referring to FIG. 4A, an illustrative processof capturing phone call data from wireline, mobile and packet switched(VoIP) telephone carriers (Carrier) is shown. In a few optional initialsteps, a phone system connector may log into the Sales Force AutomationSFA server as an administrator, at 402, and/or configuration settingsfor all users may be loaded from the backend, at 404. The phone systemconnector can log into the Carrier's platform and register to receivecall event notifications such as incoming calls, outgoing calls,declined calls, missed calls, incoming SMS, outgoing SMS, etc., at 406.The phone system connector can launch a query to the Carrier platform toretrieve all the Call Detail Records not received since last connection,at 408. The retrieved CDRs may be added to the queue of new call eventsto be processed. The phone system connector can receive notification ofa new call event for a specific user, at 410, at which point the phonesystem connector can verify if the media tracking is enabled or notenabled, at 414. If media tracking is not enabled, the process returnsto 410 to await receipt of another notification of a new call event. If,at 414, media tracking is enabled, the process can then create a calldetail record (CDR), at 416, which may include data such as date, calltype, name, number and/or user ID. Next, the call detail record may besent to the backend server, at 418, e.g., to a SFA server, a CRM server,or the like.

According to various implementations herein, data provided from thecarrier may cover, for example, mobile phone calls, SMS and landlinecalls, among others.

Further, in some embodiments, a verification step may then be performedto confirm that the call detail record was sent successfully 420. If so,the process may again return to 410 to await receipt of anothernotification of a new call event. If the send is not successful, a copyof the call detail record is saved in connection with the phone system,at 424, such as in the local phone system connector database. Then, aroutine attempting to again send the call detail record, or wait andre-send it, is performed, at 426, 428 and 432. If the re-send issuccessful, the process proceeds to a step of deleting the copy of theCDR from the phone system connector database, at 434, and againreturning to 410 to await receipt of another notification of a new callevent.

Referring to FIG. 4B, an illustrative process of data treatment andstorage into the database by the backend is shown. The backend canreceive the CDR sent by the phone system connector (cf. FIG. 4A), at440. At which point, the backend can verify that the date and time ofthe CDR are within business hours, at 442. If not, the CDR will not beprocessed, at 444. If within business hours, then the process verifiesthat the Privacy mode is not enabled, at 446. If enabled, the CDR willnot be processed, at 448. If not enabled, the process stores the CDR ina preliminary database table, at 452, at which point a trigger may besent indicating a new record has been added and ready for processing, at454. Additional attributes are assigned to the record if certainpredefined criteria are met, at 456. A partial list of these attributesmay include but is not limited to: Short call, Personal call, internalcall, etc. The process cross-references the SFA database to retrieve anyexisting SFA entity records such as Contact, Account, Lead andOpportunity, and adds the results to the record, at 458. The record isnow ready to be added to the Recorded Events database marked as Pending,at 460. The record is now viewable on the desktop application as well asthe mobile application, 462.

FIGS. 5A-5C are flowcharts of illustrative geo location captureprocessing from mobile devices consistent with certain aspects relatedto the innovations herein.

Referring to FIG. 5A, an illustrative process of capturing geo locationfrom smartphone devices is shown. In a few optional steps, the mobileapp logs into the Sales Force Automation SFA server from a mobiledevice, at 502, and/or configuration settings may be loaded from thebackend, at 504. Configuration settings may then be loaded from a mobileapplication (“app”), at 506. The app may then be registered, at 508, tolisten to geo location providers such as, for example: Wi-Fi, Celltowers (network) and GPS satellites, among others. The mobile appreceives, at 510, a new geo location notification, at which point theLocation Tracking option may be enabled or not enabled, at 514. IfLocation Tracking is not enabled, the process returns to 510 to awaitreceipt of another notification of a new geo location event. If, at 514,Location Tracking is enabled, the process then creates a Location DetailRecord (LDR), at 516, which may include data such as date and time,duration, speed, accuracy, longitude, latitude and altitude. Next, thecall detail record is sent to the backend server, at 518, e.g., to a SFAserver, a CRM server, or the like.

Further, in some embodiments, a verification step may then be performedto confirm that the Location Detail Record was sent successfully 520. Ifso, the process may again return to 510 to await receipt of anothernotification of a new geo location event. If the send is not successful,a copy of the Location Detail Record may be saved in connection with themobile device, at 524, such as in the mobile device app database. Then,a routine attempting to again send the call detail record, or wait andre-send it, may be performed, at 526, 528 and 532. If the re-send issuccessful, the process proceeds to a step of deleting the copy of theLDR from the mobile app database, at 534, and again returning to 510 toawait receipt of another notification of a new call event. Theverification step described above might be performed eithersynchronously or asynchronously.

Referring to FIGS. 5B and 5C, an illustrative process of dataaggregation and storage into the database by the backend is shown. Thebackend receives the CDR sent by the mobile app (cf. FIG. 5A), at 540.At which point, the backend may verify that the date and time of the LDRare within business hours, at 542. If not, the LDR will not beprocessed, at 544. If within business hours, then the process may verifythat the Privacy mode is not enabled, at 546. If enabled, the CDR willnot be processed, at 548. If not enabled, the process may store the LDRin a preliminary database table, at 552, at which point a trigger may besent indicating a new record has been added and ready for processing, at554.

A process of geo location aggregation of the data received may beperformed that can allow differentiating when the series of consecutivegeo locations data received describes a Route or a Static Location. Theprocess may verify, first, if the signal is arriving regularly bycomparing the time elapsed since previous LDR with a predefinedparameter, at 558. If the time elapsed exceeds that parameter, theprocess may create a No Signal record, at 560, containing the Date andTime and the duration of the no signal period. If the time elapsed iswithin the predefined parameter, then the process may use the Speed datainformation received and/or the distance between the current LDR and theprevious LDR with a predefined parameter, factoring in the precision andaccuracy of the received geo location data to determine if the user ismoving or not from previous location, at 562. If he is moving, theprocess may check if it is a new route by checking if the previous LDRbelongs already to a route, at 564. If so, the current LDR may be addedto the existing route, at 566, if not, the process may create a newroute, at 568 and add the current LDR to the newly created route, at570. If test at 562 is negative (current LDR not distant from previousLDR), the process checks if the previous LDR was in a static location,at 572. If so, the process may add the current LDR to the existingStatic Location, at 574, and if not, the system may create a new StaticLocation record, at 578, and add the current LDR to this existing StaticLocation, at 580.

After the geo location aggregation process, the process may compare theaddress of the current LDR to the user's work address, at 582, todetermine whether the user is In Office or on Site Visit. If In Office,the current LDR may be marked “In Office”, at 584. If in Site Visit, thecurrent LDR may be marked as “Site Visit”, at 588, the process thencreates a new event record and marks it as Pending for classification inthe database, at 590. The final Event Record is viewable from thedesktop application as well as the mobile application.

FIGS. 6A-6C are flowcharts of illustrative geo location captureprocessing from phone carriers consistent with certain aspects relatedto the innovations herein.

Referring to FIG. 6A, an illustrative process of capturing geo locationfrom mobile telephone carriers (Carrier) is shown. In a few optionalsteps, the mobile app may log into the Sales Force Automation SFA serverfrom a mobile device, at 602, and/or configuration settings may beloaded from the backend, at 604. The phone system connector may log intothe Carrier's platform and registers to receive geo location eventnotifications, at 606. The connector may receive, at 610, a new geolocation notification, at which point the Location Tracking option maybe enabled or not enabled, at 614. If Location Tracking is not enabled,the process returns to 610 to await receipt of another notification of anew geo location event. If, at 614, Location Tracking is enabled, theprocess may then create a Location Detail Record (LDR), at 616, whichincludes data such as date and time, duration, speed, accuracy,longitude, latitude and altitude. Next, the call detail record may besent to the backend server, at 618, e.g., to a SFA server, a CRM server,or the like.

Further, in some embodiments, a verification step may then be performedto confirm that the Location Detail Record was sent successfully 620. Ifso, the process may again return to 610 to await receipt of anothernotification of a new geo location event. If the send is not successful,a copy of the Location Detail Record may be saved in connection with thephone system connector, at 624, such as in the phone system connectorlocal database. Then, a routine attempting to again send the call detailrecord, or wait and re-send it, may be performed, at 626, 628 and 632.Once the re-send is successful, the process may proceed to a step ofdeleting the copy of the LDR from the mobile app database, at 634, andagain returning to 610 to await receipt of another notification of a newcall event. The verification step described above might be performedeither synchronously or asynchronously.

Referring to FIGS. 6B and 6C, an illustrative process of dataaggregation and storage into the database by the backend is shown. Thebackend may receive the CDR sent by the mobile app (cf. FIG. 5A), at640. At which point, the backend may verify that the date and time ofthe LDR are within business hours, at 642. If not, the LDR may not beprocessed, at 644. If within business hours, then the process may verifythat the Privacy mode is not enabled, at 646. If enabled, the CDR maynot be processed, at 648. If not enabled, the process stores the LDR ina preliminary database table, at 652, at which point a trigger may besent indicating a new record has been added and ready for processing, at654.

A process of geo location aggregation of the data received may beperformed that allows differentiating when the series of consecutive geolocations data received describes a Route or a Static Location. Theprocess may verify, first, if the signal is arriving regularly bycomparing the time elapsed since previous LDR with a predefinedparameter, at 658. If the time elapsed exceeds that parameter, theprocess may create a No Signal record, at 660, containing the Date andTime and the duration of the no signal period. If the time elapsed iswithin the predefined parameter, then the process may use the Speed datainformation received and/or the distance between the current LDR and theprevious LDR with a predefined parameter, factoring in the precision andaccuracy of the received geo location data to determine if the user ismoving or not from previous location, at 662. If he is moving, theprocess may check if it is a new route by checking if the previous LDRbelongs already to a route, at 664. If so, the current LDR may be addedto the existing route, at 666, if not, the process may create a newroute, at 668 and add the current LDR to the newly created route, at670. If test at 662 is negative (current LDR not distant from previousLDR), the process checks if the previous LDR was in a static location,at 672. If so, the process adds the current LDR to the existing StaticLocation, at 674, and if not, the system may create a new StaticLocation record, at 678, and adds the current LDR to this existingStatic Location, at 680.

After the geo location aggregation process, the process may compare theaddress of the current LDR to the user's work address, at 682, todetermine whether the user is In Office or on Site Visit. If In Office,the current LDR may be marked “In Office”, at 684. If in Site Visit, thecurrent LDR may be marked as “Site Visit”, at 688, the process may thencreate a new event record and marks it as Pending for classification inthe database, at 690. The final Event Record may be viewable from thedesktop application as well as the mobile application.

FIG. 7 is a flowchart of illustrative user classification processingconsistent with certain aspects related to the innovations herein.Referring to FIG. 7, an illustrative User Classification Process isshown. Here, the user can access directly to the list of Pending eventsthat require the user to enter a note and/or additional information, at702. The user can select one or multiple events, at 704, and select fromone of the two drop-down menus the appropriate classification thatqualifies the type of event selected, at 706. In some implementations,the choice for classification falls in 2 main categories, as shown in820 FIG. 8A, as Work Related and Not Work Related, and within each ofthese 2 categories, a configurable set of sub-categories predefined incompliance with the company's profile, as shown in 822 FIG. 8A and 830FIG. 8B. In case additional information is required, at 708, a pop-upform will pop-up with pre-populated fields from the information capturedin the pending event, at 710. The user completes the form by adding anote and/or additional information and clicks save to record theactivity in the SFA/CRM, at 712. The selected events are marked with theclassification entered by the user, at 714, and the time elapsed sincethe time the record was captured and the time it was classified isstored in the database.

FIGS. 8A and 8B are illustrations of an embodiment of a classificationprocess. The user GUI 806 displays the event data 802 pre-populated intothe GUI 806. In this case, the event data 802 is a missed call pendingclassification. The highlighted section 820 indicates a menu forclassifying the pending event data 802 into different categories such aswork related 822 and not work related 830. Once a user selects either ofthese categories, then a corresponding sub-menu appears for the user toselect a more specific description. The sub-menu 824 includes workrelated activities such as sales activity, internal management, businesssocial, IT and logistics, internal sales and general. The sub-menu 832includes personal, internal social, and benefits and HR classifications.Sidebar 804 allows a user to quickly select options such as common tasks812 and processes 814.

FIGS. 9A, 9B and 9C are illustrations of another embodiment of aclassification process. The user GUI 902 displays a set of event data914 including a selected and highlighted incoming call 916. A sidebar904 is provided and includes a sales menu 908 and manager menu 910.After the incoming call 920 event data 916 is selected in FIG. 9B, adetailed display 922 of the event data information is provided. Detailedevent data 924 includes call details and compliance status. Aclassification selection menu 926 is also displayed to prompt a user toclassify the incoming call. FIG. 9C is similar to FIG. 9B and provides adisplay 922 with a classification selection menu 930 including differentcategories than menu 926.

FIGS. 10A and 10B are illustrations of yet another embodiment of aclassification process operating on a mobile device. Event data 1002includes information such as event type, time and a user inputexplanation regarding the event. Event data 1006 displays geolocationevent data where user input has not been entered. Selections 1004 aredisplayed where a user classifies the event as work related and morespecifically, as a sales event. Selections 1008 illustrates a not workrelated classification for a personal event.

In order to provide purely data-driven, actionable business insightsregarding Sales Productivity and Forecasting as well as TechnologyAdoption and Adherence, some implementations herein may aggregate and/orcross-references data streams and sources such as Presence ManagementSystems/“Multiple Points of Presence” (“MPOP”) data, mobile phones,local PBXs (whether circuit or packet-switched/Voice over IP/“VoIP”),VoIP phone services, computing devices such as desktop computers, laptopcomputers, smart phones, tablets, servers, databases, networks, networkcomponents, etc., Geo-location (GPS) data, Sales Force Management/SalesForce Automation SFA systems, CRM system data, electronic calendar dataand/or credit card transaction data, among other inputs.

Certain implementations herein may be broken down into and/or involveone or more of three key aspects (each of which address the core issuesof adoption, data integrity and productivity. The first is alarms (andassociated alarm notification mechanisms). The second is reports. Thethird is extrapolated insights, which includes but is not limited topattern matching and modeling.

Implementations herein may leverage the data streams noted above andcross reference them to identify discrepancies between factual, mineddata versus data entered by staff; and they may generate alarms whenlead generation and sales processes are not followed. Such eventprocessing may be (i) used to generate alarms; (ii) available inhistorical reports, and; (iii) used to provide extrapolated insightsregarding individual productivity, group productivity and productivitymodeling.

The innovations contained herein include user adoption facilitation andenforcement mechanisms that provide customizable, automated alarmreminders to users that escalate with the passage of time, ultimatelytriggering a different alarm for the salespersons' manager once the lackof compliance reaches a preset, customizable threshold. This alarm canbe displayed in the user interface or sent by email, SMS text messageand other methods.

Certain systems and methods herein also include productivity oversight,data quality and/or user adoption monitoring and enforcement mechanisms.Here, for example, implementations may include alarms when discrepanciesbetween relevant data streams and self-reported data are identified sothat managers can be alerted to “Integrity Incidents” whereinsalespeople may be unintentionally misleading themselves orintentionally misleading others. These discrepancies may beevent-specific, such as the length of site-visits and other meetings orthe duration or quantity of phone calls or emails. They can alsoidentify leads that have not in fact been pursued in accordance withprescribed sales methodologies, if at all. Integrity can also be managedfrom the perspective of absences from work (for both office andhome-based employees) in that such absences can be tracked viageo-location and cross referenced with electronic calendar and othersystems to identify cases where absences have not been listed asvacation or personal days. Also, the integrity of mileage expensereports and expensed client dinners are analyzed (for example, were theyactually there on the day listed on the receipt?) which are now subjectto verification on an automated basis. Since employees always have theability to turn off geo-location tracking on their mobile devices (andthey can also turn off CDR [Call Detail Record] tracking of telephonecalls on their mobile phones via our mobile application forjurisdictions where this may be legally mandated), the system willdetect that such tracking has been disabled, check the relevantelectronic calendar to determine whether the employee has taken personaltime or is travelling by air, and if appropriate, will alarm managers(in software dashboard notifications and/or email and/or SMS), and inreport form, that user tracking has been disabled. (These alarms mayresult in follow-on investigation if warranted). If tracking is done viathe carrier the system will nevertheless track when location services orCDRs are disabled and enabled for purpose of data filtering within thesystem. Managers can also set time-interval thresholds for disabledtracking notifications, to ensure that moments of signal loss (such asin elevators or parking garages) do not generate unnecessarynotifications. Productivity alarms include manager and user notificationwhen activities fall below a defined threshold. In the case of SalesForce Management and Sales Force Automation systems, these productivityalarms can be configured to monitor and alarm productivity deviationsfrom prescribed policy in all stages of the sales process, which can bedefined on a custom basis or by default include but are not limited to:new opportunities, initial communications, the fact-finding phase, thesolution development phase, the solution proposal phase, the negotiationphase, the purchase order phase and account maintenance phase. Ifproductivity as defined by the manager in terms of sales relatedactivities tracked by the system (as described herein) do not meet thedefined threshold for a given phase in the sales process, then themanager may also receive alarm notification in the form described above.Further, productivity alarms may also be defined in the context ofoverall time allocation tracked by the system (as described herein),such that neglected activities will also trigger alarms in the formdescribed above.

In addition to such alarms, sales managers also have access to detailedcompliance dashboards and displays and detailed reports including butnot limited to user adoption, productivity, sales process adherence anduser integrity. Additional details on these processes are includedbelow.

Systems and methods herein may include user adoption monitoring andenforcement mechanisms such as implementations that may include reportsand alerts that flag non-compliance with policies regarding timely dataentry following activities such as live meetings (via geo-location andelectronic calendar and/or SFA information), phone calls (mobile orPBX—including packet-switched voice over IP “VoIP”), SMS exchanges,email exchanges, faxes sent or received and/or chat sessions. Thesemonitoring and enforcement mechanisms may also be applied to timely dataentry regarding meeting cancellations, the time-lag between eventsrequiring data entry and the follow-up data entry. Failure to enter datainto Sales Force Automation and other systems can be followed up byautomated warnings and Manager alerts. More detail regarding adoptionenforcement and facilitation this as well as notification and otherconfiguration options are set forth elsewhere herein.

Systems and methods herein include extrapolated insights regarding thequality of leads in the pipeline at each stage of the sales process. Forexample, by correlating the number and length of live meetings (viageo-location), phone calls, emails and chat sessions with adynamically-updated, data-driven model of sales cycle assumptions (whichare dynamically updated with real-world data on successful salesprocesses), conclusions may be drawn about the likelihood of asuccessful sales outcome for a prospect in a salesperson's salespipeline. Pipeline verification analysis advises when the amount ofcommunication to date relative to the success model conflicts withsalesperson optimism—to invite further exploration by sales managers.

Systems and methods herein include time allocation analysis ofindividuals and groups analyzed in the context of dynamic successmodeling. Managers and salespeople themselves can view their ownproductivity reports to gain insight on their time allocation byactivity type, account value, qualified versus unqualified leads, salesfunnel stage (including: prospecting, new opportunities, initialcommunications, fact finding, solution development, solution proposal,solution evaluation, negotiation, purchase order, etc.), time allocationon sales versus non sales (internal) activities, as well as the speedand quality of their follow-up. Allowing employees to see thisproductivity-related information allows them to both challenge theirsubjective perceptions to self-assess their efforts and gain insight onwhat adjustments can be made to improve performance. To this end,implementations may provide salespeople the opportunity to contrast andcompare their time allocation to that of another salesperson and/or acomposite of the top X % of salespeople and/or to the team in general.Over time, productivity modeling can enable salespeople to process howchanges in their own productive behaviors can impact on their salesperformance. For the manager, implementations can enable productivity tobecome a dashboard metric with associated alarms and configurablereports. The modeling component provides managers with valuable insightson where productive efforts should be focused in the context of specificproduct lines while also providing the business insight required formentoring and assessing sales staff. Implementations of productivityanalysis can also provide insight for more effective sales territorymanagement by enabling managers to distinguish between ‘order takers’who make little effort to obtain new business and salespeople who makeheroic efforts to meet their sales quota. This distinction can providemeaningful insight on when sales territories should be split andarguably provides a superior metric to the most common practice ofsplitting sales territories when they reach sales quota targets.

Systems and methods herein include cross-referencing of individual andgroup time-allocation analysis with a dynamically-updated, data-drivensuccess model of sales process effectiveness to identify time allocationinefficiencies. This success model may be derived from the analysis ofsuccessful sales events and includes an analysis of the number ofcommunications with the prospects and their duration, including phonecalls, chat sessions and emails, as well as the number and duration oflive meetings, expensed business meals (business lunches/dinners), thenumber and duration of communications following significant milestonesin the sales process (such as the response to a Request for Proposal),as well as the duration of time elapsed between communications.

Systems and methods here include time allocation analysis to monitortime spent on sales activities relative to the size of the initial salesopportunity and/or the size of the potential opportunity in the future;(with data related to time spent derived by analyzing the number andlength of live meetings, phone calls, emails and chat sessions as wellas internal communications related to sales opportunities).Implementations with time allocation analysis features may also provideactionable insight to managers regarding excessive personalcommunication by staff during business hours. Embodiments including timeallocation analysis can also provide actionable insight on time spent oninternal activities versus customer-facing revenue-producingactivities—to draw attention to time management issues as well asstaffing shortages (for example in in product managers, sales engineers,etc.) that are diverting salespeople from a singular focus on revenueproduction.

Systems and methods herein may be configured for identification ofneglected opportunities by cross-referencing prospect inquiries and leadlists with actual follow-up by sales staff across all communicationschannels: phone calls, emails, fax, chats and live meetings.

Systems and methods include integrity monitoring and enforcementmechanisms. Here, for example, implementations may include crossreferencing of data entries with live meetings (via geo-location), phonecalls (which in all cases herein include mobile phone calls or PBX phonecalls—including packet-switched Voice over IP [“VoIP”] phone calls),faxes, email exchanges and chat session/SMS analysis to advisemanagement of potentially inaccurate or wrong information contained inuser data entries. Implementations can also include cross referencingdata entries with live meetings (via geo-location), phone calls (mobileor PBX including packet-switched voice over IP “VoIP”), faxes, emailexchanges and chat session/SMS analysis to advise management ofpotentially inappropriate communication with competitors. In addition,implementations can include geo-location tracking analysiscross-referenced with mileage expense report submissions to determinethe true level of reimbursement that is warranted. Implementations mayalso include geo-location tracking analysis to track inappropriateabsences from work (long lunches, personal time not entered as ‘personaldays’, too much time spent in offices of people with whom the employeehas no professional interaction, too many outdoor breaks, etc.).Implementations can also include the ability to detect and identify anabsence of any work-related activity: such as live meetings (viageo-location), internal or customer phone calls, faxes, email exchangesor chat sessions; in order to to identify employees that may beintentionally slowing down sales to avoid a territory split or who aresimply derelict in the professional responsibilities.

Systems and methods herein include various features that providevalue-add for purposes of employee adoption of SFA systems. Among otherthings, implementations herein provide for increase in adoption byreducing data entry requirements. Further, adoption is also increase byalerting managers regarding non-compliance. The fact that non-complianceitself can now be tracked will in and of itself impact on user adoptionprocess adherence. According to some systems and methods, alarms areprovided when communications or meetings are not followed up with notesin the CRM system, and some implementations utilize various colorsand/or changes in color levels as time elapsed. Reports may also begenerated including information as to how long the person waited beforeentering the data, as time lag correlates inversely with accuracy.Alarms are also provided for missing data entries. Here, for example,alerts may be issued to managers regarding events such as calls, chatsand meetings not entered into SFA.

Systems and methods herein include various features that providevalue-add with respect to productivity, such as via various productivityalarms. In some implementations, reports and/or alarms may be generatedwhen discrepancies arise between hard data and employee data entries.Here, for example, such reports and/or alarms may be generated whendiscrepancies regarding time spent on opportunities are detected, whenprospects/leads have not actually been called, and/or when differencesbetween actual versus reported time spent prospecting to fill the salesfunnel are noted. Reports and alarms may also be generated forquestionable data entries. Here, for example, such indicators may flagaccounts where the amount of communication to date seems to conflictwith salesperson optimism. Additionally, these contrasts may be furtherextrapolated, such as by generating data-driven conclusions with salesforce data-entry projections. Here, for example, sales pipelineverification analysis can include how many calls, length of calls,number of visits, length of site visits, etc. Reports and alarms mayalso be generated to help management become aware of inappropriatecommunication with or visits to competitors or headhunters, andimplementations herein may detect such events regardless of which emailclient is used. Alarms and warnings may also be generated for excessivepersonal communications during business hours. Additionally, reports andalarms may be generated to flag time actually spent in internal meetingsvs revenue production.

Systems and methods herein include innovations that provide for highintegrity and analytics, such as features offered by features of the bigdata analytics herein. Here, implementations may identify conflictsbetween personal data streams and self-reported data, and may presentsuch information both as manager alarms and as data available inreports. For example, reports may include time spent on opportunities,leads not called, prospecting/cold calls not done, etc.

Systems and methods herein may also include or involve innovationsassociated with other integrity related alarms and reports.Implementations may include virtual punch clock features (e.g., viageo-location), offsite lunch duration tracking, mileage expense analysis(e.g., true miles travelled versus submitted mileage expense report),and/or absences not listed as vacation or personal days. Implementationsmay also involve features of personal communications analysis (e.g.,personal calls, Internet data chat sessions, etc.), personal Web-surfingtime analysis, and/or personal web usage analysis (e.g., personal versusbusiness use). Further embodiments may include functionality related toheadhunter call tracking (e.g., to identify at-risk employees),competitor call tracking (e.g., communications with competitors), and/orcontact with other parties of concern. Integrity management featuresherein may also be configured to detect data indicating that anintentional sales process slowdown (usually because quota has beenreached). Additionally, systems and methods may include features thattrack the integrity of entertainment expenses (e.g., to track expensesas well as location and time, etc). Here, for example, implementationsmay be configured with features monitoring geo-location and performingcredit-card analysis, which help eliminate the issue of restaurantreceipts submitted for different days than the actual restaurant visits(e.g., able to demonstrate that a business meal with a prospect may nothave taken place, etc).

Systems and methods herein may also be configured to perform variousorganizational behavior barometrics and analytics. Here, for example,implementations may analyze aggregate communications traffic withinorganizations to flag when internal/external call traffic ratios suggestthat employees are commiserating in an unusual traffic pattern, e.g.,suggesting that there are company rumors that need to be addressedinternally for productivity to be restored to standard levels.

Present systems and methods may also be configured for implementationvia various deployment models. For example, the innovations herein maybe offered both as a premises-based solution(s) for large enterprisesand/or as hosted SaaS (“Software As A Service”) solution(s) to empowercompanies of all sizes to leverage system-based pattern-detection inboth their strategic and tactical decision-making, in all phases of thesales and sales-forecasting process. For those operating in the SaaSmodel, an anonymous comparative analysis opt-in program may allowworkgroups to compare their performance and success models with otherworkgroups similarly tasked in similar organizations.

Systems and methods may also configured with features to innovativelyprocess various data streams. For example, implementations may analyze aset of data streams which may be called Personal Event Data Streams(“PEDS”) and a proprietary Data Stream Event Processor (“DSEP”) toprocess and extrapolate insights regarding individual performance,productivity, potential fraud and adherence to company policiesregarding software adoption. As part of this process, the aggregate datastreams from multiple new and existing data streams may store theresulting “big data” in a dedicated event-stream repository (a dedicatedset of database tables).

Personal Event Data Stream processing is achieved via algorithms thatlook at a variety of variables including (a) identifier(s), (b) regularhours of activities, (c) locations of users, such as those obtained viageo-location (e.g., via dedicated apps installed on company mobiledevices), integration with premises security system to cross referenceuse of physical security badges, Wifi hotspot, IP address, etc., (d)calls, including but not limited to mobile phone, IP phone, officephone, logs of phone provider, etc., (e) electronic conversations,including but not limited to chat, mail, Instant Message, etc., (f)presence status, (g) computers activity tracking, including but notlimited to key loggers, tasks manager, etc., (h) electronic agenda, CRM,and Sales forces management type data, including but not limited tocontacts, opportunities, accounts, leads, appointments, calls, etc., and(i) business credit card logs.

In systems and methods herein, users may enter their activities usingdifferent CRM, Sales Force Management (“SFM”) or electronic calendarsoftware. In addition, users may declare holidays or sick days on ERPand/or calendar software. Each of these is a data stream resource forthe solution.

Implementations may be configured for use with additional systems ordevices such that a company may deploy, manage systems and allocateprofessional devices to improve the efficiency of their employees. Suchsystems and devices include but are not limited to mobile phones, officePBX and/or IP phones, desktop and laptop computers, tablets andsmartphones, presence management systems, email servers, GPS, andbusiness credit cards.

Systems and methods herein may be configured to collect and process datafrom user devices and company software in order to generate user PEDS(Personal Event Data Streams) and store them in the database(s). Presentimplementations may also collect user's “declared activities”(information entered by the user) from relevant software (SFM,electronic calendars, ERP . . . ). Further, PEDS may be stored intoAnalytics database tables. Embodiments herein may extrapolate from PEDS(for example, true duration of all customer meetings in the salesprocess, number and duration of all phone calls, etc.—to identify, amongother issues, questionable sales projections based on a dynamicallyupdated model of the typical sales process for a given product orservice. Such processing may also be used to identify fraudulent entriesin the sales force management software. A Data Stream Event Processor(“DSEP”) may also be utilized for performing these extrapolations.Further, reports and alarms may be derived or extrapolated from thesePEDS. In some implementations, the DSEP may construct a “success model”by analyzing successful sales transactions in the pipeline as reflectedin the Sales Force Automation system and cross-referencing them againstthe “big data” in the PEDS to create dynamically-updated PEDS successmodels. In other words, such processing may identify opportunities inthe sales pipeline where there have been insufficient numbers ofcommunications (in calls, emails, live meetings and site visits, etc.)to justify the optimism of the salesperson from a statisticalcorrelation perspective.

In still other implementations, such as when companies opt-in to the“industry comparative analysis modeling” program, systems and methodsherein may be configured to anonymously contrast individual (by role)and/or group performance data with counterparts at other companies ofcomparable size in comparable industries.

FIG. 11A is a flowchart illustrative of Adherence facilitation mechanismprocessing consistent with certain aspects related to the innovationsherein. An illustration of facilitation mechanism process is shown inFIG. 11A. Events related to sales activity are captured throughConnectors and/or mobile apps, and stored in the database, at 1102, asshown in FIGS. 2A, 2B, 3A, 3B, 4A, 4B, 5A, 5B, 5C, 6A, 6B and 6C. Whenan event is captured, the process cross-references it with existingSFA/CRM database in order to find additional information regarding theevent. The results, (Contact, Lead, Account, Opportunity or any SFA/CRMentity), will be added to the captured event, at 1104. When the userselects the captured event to classify it, at 1106, following theprocess shown in FIG. 7, the process will be able to auto-populate thefields with the information contained in the captured event, at 1108,including the results from cross-referencing with SFA database. Thiswill allow the user to save time and avoid human error. In the nextoptional steps, the process checks if the event is an SMS, at 1112, andif so performs a process of aggregation which purpose is to group allconsecutive SMS with same recipients into a single SMS conversation, at1114. SMS are subject of repeated messages sent back and forth that areall related into the same conversation and the aggregation processavoids the user to deal with a multitude of SMS to classify. The processfurther checks if it is a geo location, at 1116, and if so, the UI willdisplay a visual map showing all the routes and visits of the day, at1118, allowing the user to easily recognize the meeting he needs toclassify. The process will look in the scheduled events if matchingmeetings located nearby exist and list them next to the captured visitsand routes, at 1120.

FIGS. 11B-11C are illustrative user interface showing exemplaryfacilitation mechanism processing features consistent with certainaspects related to the innovations herein. FIG. 11B shows theauto-populated feature, at 1128. The fields shown in 1128 have beenpopulated with the information contained in the captured event, allowingthe user to save time and avoiding human error. The SMS conversation isshown at 1130, where all the consecutive SMS displayed in the ActiveOphio SMS conversation list. FIG. 11C shows the auto-populated fieldsfor a geo location, at 1132, and a visual map of routes and visits, at1134, as well as the nearby scheduled meetings.

FIG. 11D is an illustrative user interface showing exemplaryfacilitation mechanism processing features consistent with certainaspects related to the innovations herein. FIG. D shows how facilitationis performed on a mobile application, at 1140. The auto-populated fieldsare shown at 1146. The user enters the note in an appropriate field at1148.

FIG. 12A is an illustrative user interfaces showing exemplaryenforcement mechanisms processing. Referring to FIG. 12A, an exemplaryembodiment of how enforcement mechanisms may be performed in theMicrosoft Dynamics environment is shown. As set forth, herein, if a userhas recorded events that require classification the user can be promptedto classify these events in a timely manner. Preconfigured adherenceprofiles may be utilized to configure Adherence alarms and notificationsfor users and Managers. For example, various adherence profiles mayallow an administrator to specify: 1. The Alarm notification intervali.e. how often to send an alert to the user once an alarm has beentriggered (1208); 2. The different levels of escalation, such as viacolors, for example, Yellow, Orange and Red and their respective defaultthresholds (1204); 3. If a notification should be sent for a specificlevel of escalation (1210); 4. The means to use for notifications (Feedsor email) (1202); 5. The list of recipients for notifications (1214);and/or 6. individual time thresholds per event type that overwrite thedefault (1212). Administrators and/or management entities may createmultiple Adherence profiles and assign different users to differentprofile for maximum flexibility.

FIGS. 12B-12C are flowcharts of illustrative adherence enforcementprocessing consistent with certain aspects related to the innovationsherein. Referring to FIG. 12B, an illustrative process of adherenceenforcement is shown. In a few optional steps, the process identifiesall the adherence profiles associated to the users that have eventspending classification, at 1212. This will limit the number of profileto use in the following process. The process loads these profiles at1214. A system administrator may define as many levels of escalation asneeded. This process uses profiles to identify compliance levels foreach event in pending state, at 1216. A pending event can move from alower level of compliance to a higher level of compliance as defined byprofile. The process uses the user profiles to identify all the pendingevents that are candidates to be set to the current threshold level, at1218. Then, for each event, the process computes duration on the pendingstate, at 1220. The process identifies the events that have alreadyreached the current threshold level, at 1222. Once these event areidentified we set the compliance level to the one associated to thecurrent threshold level 1224. Referring to FIG. 12C, an illustrativeprocess to generate new alarms is shown. One aspect of this process isto control the number of generated alarms for each user. The userprofile defines a time interval for generating alarm. The process willnot generate an alarm with the same or lower level than the last sentalarm within the time interval. The process starts by loading thecurrent alarms for all user candidates to receive new alarms 1230.Current alarms may be all alarms that are still with the time interval.For each user the process computes the number of pending events percompliance level 1232. If the user has events with compliance levelsthat are worse than the ones that have been included in the last alarm,then the process generates a new alarm, at 1234. The process will send anotification for the newly generated alarm as per the user adherenceprofile 1236. Eventually, his or her manager will get the samenotification.

FIG. 12D is an illustrative user interface showing exemplaryfacilitation mechanism processing features consistent with certainaspects related to the innovations herein. FIG. 12D shows enforcementmechanism processing performed on the mobile app by showing a pie chartof the adherence level of the user, at 1244. The pie chart shows thepercentage of each pending events per threshold level (in this case, Notlate, Late and In default) giving a quick and straightforward summary ofthe user's compliance with the company's Adherence policy. FIG. 12E isan illustrative user interface showing exemplary facilitation mechanismprocessing features consistent with certain aspects related to theinnovations herein. FIG. 12E shows how enforcement mechanism isperformed on the desktop application within Microsoft Dynamics byshowing a pie chart of the adherence level of the user, at 1262. The piechart shows the percentage of each pending events per threshold level(in this case, Not late, Late and In Default) giving a quick andstraightforward summary of the user's compliance with company'sadherence policy. An example of enforcement notification is shown at1270 where the user is being warned through the Feeds that he hasreached level Alarm3 inviting him to take necessary action.

FIG. 13A is a flowchart illustrating an exemplary set of integrityincident identification mechanisms. At 1302, the integrity incidentidentification mechanism begins with a user self-reporting a new eventin a software system that typically relies upon manual data entries,such as a CRM or sales force automation/salesforce management system. At1304, the system then cross-references that self-reported data againstthe aggregated data derived by the methods and processes described inStep 1. At 1306, the system first determines whether a matching recordedevent has already been created and added to the list of events thatrequire manual processing of the data in accordance with step 2 herein.At 1308, if a matching recorded event exists in the aggregated data andhas already been created and added to the list of events that requiremanual processing of the data in accordance with step 2 herein, thesystem then determines if manual processing and classification hasalready taken place or not. If no manual processing and classificationhas already taken place and the self-reported event matches a recordedevent, then the self-reported event is compliant and no further actionis warranted. At 1310, if (following 1308) manual processing andclassification has already taken place then a “DUPLICATE EVENT”Integrity Incident is created and the user and/or his manager will benotified of the duplication by the method configured by the manager,which may include email and or SMS and/or a notification in thescrolling feed of the user and/or the manager. At 1316, if a matchingrecorded event does not exist in the aggregated data and has thereforenot already been created and added to the list of events that requiremanual processing of the data in accordance with Step 2 herein, thesystem then determines whether a different conflicting event has beenrecorded in the aggregated data (derived by the methods and processesdescribed in Step 1) that contradicts the self-reported data. (Forexample, a self-reported data entry of a call with a prospect between 9am and 10 am would be contradicted by recorded event of a personal callthat took place between 9:00 am and 9:45 am that same morning. Anothertheoretical example would be a self-reported event of a meeting with aprospect at their offices at the same time as the geolocation dataplaces the employee at the baseball stadium). At 1318, if acontradicting event does exist, then a “CONFLICTING RECORDED EVENT”Integrity Incident is created and the user and/or his manager will benotified of that Integrity Incident by the method configured by themanager, which may include email and or SMS and/or a notification in thescrolling feed of the user and/or the manager. At 1320, if a matchingrecorded event does not exist in the aggregated data and has not alreadybeen created and added to the list of events that require manualprocessing of the data in accordance with step 2 herein, and the systemdetermines that a different conflicting event has not been recorded inthe aggregated data (derived by the methods and processes described inStep 1), then the system will determine whether a partial match exists.See 1322 for an example of a partial match. At 1322, if a partial matchexists (for example, the data shows that a call took place with thespecified party at the specified time, but the call duration was only 5minutes and NOT the 50 minutes that the user manually entered into theirsystem), then a “Discrepancy With A Recorded Event” Integrity Incidentis created and the user and/or his manager will be notified of thatIntegrity Incident by the method configured by the manager, which mayinclude email and or SMS and/or a notification in the scrolling feed ofthe user and/or the manager. At 1324, if a partial match does not exist,then a “NO MATCHING EVENT” Integrity Incident is created and the userand/or his manager will be notified of that Integrity Incident by themethod configured by the manager, which may include email and or SMSand/or a notification in the scrolling feed of the user and/or themanager.

FIG. 13B is another flowchart illustrating an exemplary set of integrityincident resolution mechanisms. At 1322, the user selects and integrityevent to process from their integrity—four or one of their integrityevent lists or by clicking on a link included in the notification allthe integrity event sent to them in their data feed or email or SMS textmessage. At 1326, the user has the option to delete the self-reportedevent that triggered the integrity incident. At 1328/1330, if the userchooses to delete the self-reported event that triggered the integrityincident, then that self-reported event is deleted and the integrityincident record is marked as “Resolved.” At 1332/1334/1336, if the userchooses not to delete the self-reported event that triggered theintegrity incident but to modify it instead, then modification isentered and the integrity incident identification mechanism's process(in FIG. 13A) is repeated. At 1338/1340/1342, if the user chooses not todelete the self-reported event that triggered the integrity incident anddoes not modify it, the user is provided with an opportunity to enter anexplanation that will be appended to the incident record that will besent to the manager. The user interface provides a form for the user toenter that explanation. Once appended with that explanation, theintegrity incident is marked as “EXPLAINED PENDING MANAGER APPROVAL.” At1344/1346, if the manager approves the explanation, then the IntegrityIncident is marked as “Resolved By Explanation.” At 1348, if the managerdoes not approve the explanation then the integrity incident record isreset to its original state as set forth in connection with FIG. 13A.

FIGS. 14A-14B are flowcharts of illustrative processing consistent withcertain aspects related to the innovations herein. In the adherencealarm exception request processing of FIG. 14A, at 1402, the systemdetermines that an Adherence Alarm has been triggered. The AdherenceAlarm occurs when a user fails to follow company policy for example if aphone call from a lead is not classified within 24 hours, an AdherenceAlarm will be created. At 1404, a notification can be sent to either theuser or the user and his manager depending on the user's profileconfiguration. At 1406, when the user reviews the alarms that he hastriggered (either by navigating to the appropriate tab on the CRM ormobile client or by receiving a specific Adherence Alarm. The user maysubmit a request that an exception be made because there is a validexplanation. The user must enter the reason and request that the managerreview the request. The user may submit the request through the Userinterface or mobile client. At 1408, when the manager receives theexception request, he must review the request and decide whether or notto accept the user's reasoning. If the manager does not respond to therequest in the timeframe specified in his profile, the manager willreceive notifications that the exception request is pending. At 1410,the manager can decide to approve or reject the request at hisdiscretion but the record remains in the database. At 1412, if themanager rejects the explanation the record of the alarm stands. At 1414,if the manager accepts the users request the Alarm record is closed withan exception approved by manager and this will not appear in the alarmreports. At 1416, the user is informed that the request was accepted andno further action is required.

Referring to the integrity incident processing of FIG. 14B, at 1420, thesystem determines that an integrity incident has occurred. The integrityincident occurs when user reported data is in conflict with machinereported data. For example an integrity event can be due to the userreporting a call to an opportunity but the call was made from a 3rdparty phone or the user reported a site visit duration of an hour whenthe geo-location data reports that the visit was actually only 30minutes. At 1422, a notification can be sent to either the user or theuser and his manager depending on the user's profile configuration. At1424, when the user reviews his assigned incidents (either by navigatingto the appropriate tab on the CRM or mobile client or by receiving aspecific integrity incident notification. The user may submit a requestthat an exception be made because there is a valid explanation. The usermust enter the reason and request that the manager review the request.The user may submit the request through the User interface or mobileclient. At 1426, when the manager receives the exception request, hemust review the request and decide whether or not to accept the user'sreasoning. If the manager does not respond to the request in thetimeframe specified in his profile, the manager will receivenotifications that the exception request is pending. At 1428, themanager can decide to approve or reject the request at his discretionbut the record remains in the database. At 1430, if the manager rejectsthe explanation the integrity event stands but the user can stillresolve the integrity event in the usual manner described in FIG. 13B.At 1432, if the manager accepts the user's request the incident isclosed with an exception approved by manager and this incident will nottrigger alarms or notifications and will not appear in integrity reportsas an integrity event. At 1434, the user is informed that the requestwas accepted and no further action is required.

Systems and methods herein may also be configured with mechanism fornotification management. FIG. 14C illustrates an exemplary userinterface showing adherence policy features and functionality. In someimplementations, systems may be configured with 5 default adherenceprofiles, though systems are also configurable to customize those 5policy adherence profiles or add an unlimited number of additionalcustom policy adherence profiles, at 1440. An aspect of such policyadherence profiles is to define the quantity and types of alerts thatare escalated to the manager. A policy adherence profile is a definedset of configurations of the policy definition, escalation andnotification processes, which determine the quantity and variety andvelocity of notifications that will be sent to the manager. Each ofthese policy adherence profiles elicit different triggers for alerts anddifferent frequencies for notifications and alarms. A policy adherenceprofile can include all of the configuration options referenced hereinand can be applied in defined circumstances including by named employee,by named prospect or customer, by event type, by opportunity type/size,by total historical customer value, by immediate and long-termopportunity value and many other parameters.

In the illustrative (default) implementation, a first default policyadherence profile essentially turns off the alarms and notifications.The user can view dashboards at his leisure to verify his assumptionsabout his progress. The system then acts as a tool that is used by theuser to increase awareness and help in the sales process but it does notcontinually alert the user or the manager of the tasks that needattention. Here the system is restricted to being a tool to advise usersof events rather than a method to monitor and to control theircompliance with policies on how those events should be followed up on.The manager will nevertheless be capable of accessing data generated oraggregated by the system as well as access the tools based on that data.The second default policy adherence profile turns off the notificationsto the manager but leaves the rest of the system processes for adoptionenforcement and facilitation, integrity management and productivityanalysis in place. Here the manager will periodically rely on reports tounderstand and evaluate user adoption, integrity and productivity butwill not manage user activity on an event-by-event basis. Each of theremaining profiles sequentially increases the number of triggers formanager and/or user notifications; reduces or increases the timeduration interval for a notification to be initiated; and reduces orincreases the frequency of user and manager notifications. The lastprofile has the greatest number of alarm and notification triggers.Users and managers are prompted at shorter intervals throughout the dayas to how many tasks require completion. Managers receive updatesthroughout the day providing many more details about the useractivities, adherence delays and generated integrity issues. Here theapplication is used primarily as a tool to consistently manage usersactivities and compliance and enforce company policies regarding everyevent.

An administrator or manager can apply each of the 5 policy adherenceprofile levels in their default state or they can be modified for aparticular circumstance as noted above or for all instances in which theprofile has been applied. As the manager uses the system and becomesmore aware of which notifications he wishes to receive and how often hewishes to receive the relevant notifications, the manager can modifywhich modified or unmodified policy adherence profiles should apply ineach circumstance. The adherence profile definition can also leverageand be based on the data views available in the SFA/CRM. These dataviews provide a flexible and powerful method to further define thecriteria and conditions that will trigger notifications and alarms. (Forexample, a manager can choose to use a system data view to filter allthe opportunities with an estimated closing date for the current quarterand an estimated deal value that is greater than one million dollars inorder to have greater insight and enforce alarms and notifications onthose specific opportunities).

Systems and methods herein may also include privacy managementmechanisms. Here, for example, implementations may have a mechanism toidentify when a geo-location device has gone silent. There are manypossible reasons that this may occur: no cellular service, travel on anairplane or if a user opts to disable geo-location tracking. Referringto the exemplary process regarding such situations shown in FIG. 15, at1502, the server detects that a user's geo location device has stoppedtransmitting for a period that exceeds a predefine threshold. At 1504,the system evaluates if this incident happened during business hours forexample between 9 am and 5 pm. At 1506, if not during business hoursthis incident is ignored. At 1508, the system evaluates if this incidenthappened during approved time off, for example a sick day. At 1510, ifthe incident occurred during an approved time off this incident isignored. At 1512, if the incident occurred during business hours and notduring an approved time off than an incident is created. At 1514,depending on the user profile a notification may be sent to the userand/or his manager.

FIGS. 16A-16F are flowcharts and illustrative user interfaceimplementations showing time allocation and productivity analysisprocessing consistent with certain aspects related to the innovationsherein. The User interface can produce a visual representation of timeallocation and user productivity analysis. This can be represented as asummary or broken out by user. Referring to FIG. 16A, at 1602, in theuser interface or mobile client the user must enter a valid start andend date to include in the report or chart. At 1604, the user may selectwhich users or groups of users to include in the report or chart. At1606, the user selects whether to view the report as a summary or brokendown in a number of ways including but not limited to: by user, by time,by customer facing activity, by work related or not work relatedactivities. Here, see FIG. 16B. At 1608, the client sends a request tothe server. At 1610, the Server receives and parses the request. At1612, the server builds a query that will return the results that showhow the user has spent his time. This “time allocation and aggregationquery” leverages the classification process (described in step 2 andrelated flowcharts and figures of this document) the query factors inthe business hours, approved time off and approved exceptions. At 1614,the server retrieves and processes the query results. At 1616, theserver builds a response and sends it to the client. At 1618, the clientreceives the response from the server and displays the results in therequested format (ex. Charts, reports, etc. See FIGS. 16B and 16C.

Referring to FIG. 16D, in order to bring objectivity to the process ofterritory management for sales teams, the system tracks the effortrequired by users to make quota. At 1626, a user can report that anactivity has occurred through the User interface or mobile application.At 1628, the system captures the new activity in the database and savesa snapshot of the current state of the related SFA/CRM data such asAccount, Opportunity stage, Opportunity value and Opportunity closingprobability. This snapshot is saved in a database for later comparisonto identify trends and activities taken or not taken by the users. At1630, this process leverages the “integrity incident identificationmanagement” process in Step 5 to determine if the newly created snapshotcontains any integrity incidents. Integrity incidents are observed whenuser reported data is in conflict with machine reported data. At 1632,the system presents the user with multiple graphical charts in order toprovide a more accurate view to the data and level of effort required bya salesperson to reach quota. In the first calculation the system usesall the historical snapshots in order to track the sales process anddetermine the level of effort exerted in a specified territory over agiven period of time. At 1634, in the second calculation the systemfilters out all the historical snapshots that contain integrityincidents, the two charts are placed side by side in order to presentthe user a clear picture of how much the integrity incidents haveaffected productivity, time allocation and sales. At 1636, the resultsare displayed to the user with different chart types such as EffortSummary, Effort per Week and Effort per Opportunity Sale Stage in orderto present a fuller view of the user's efforts and how they are affectedby different variables. See FIGS. 16E and 16F. At 1638, once the userhas verifiable data that can objectively assess the level of effort abetter decision can be made whether or not to split the territory. Thesecharts give the user a visual representation of the aforementionedverifiable objective data and the level of effort required in theterritory.

Various innovations contained herein in the area of forecast analysisare different from all existing alternatives in one or more of three keyrespects. First, analysis herein relies on machine data. Second, it doesnot use any user-entered data other than the data classificationmechanisms outlined above (any subjective perceptions of the user areexcluded). Third, the approach to analyze and remove opportunities fromthe sales pipeline rather than finding the ones to include in it. Assuch, it functions more as a ‘last step filter’ of the sales pipeline.An approach of innovations herein is to introduces a fact-baseddimension to sales pipeline analysis that reviews the opportunitiesplaced in the pipeline by salesperson or manager instinct or by otheranalytics products. Since user-defined events are generally incompleteand often inaccurate, this approach is far more effective when the datais machine-generated. This fact-based method tracks the relevant eventsfor each opportunity at stage in the sales process. Examples of factbased dimensions may be: Incoming Call for Sales Stage 1, Incoming Callsfor Sales Stage 1, On Site Visits for Sales Stage 1 and Emails for SalesStage 3. The set of all the possible fact-based dimensions defines thecanonical vector base. The canonical vector base permits to express allthe efforts in term of duration in time for all the stages of a givenopportunities. The set is said to be canonical because it is a completeand minimal. The canonical vector base is used to represent all theactivities, based on machine data recording, for a given opportunity.For example, giving the following subset of the fact based dimensions:Incoming Call Stage 1, Incoming Call Stage 2, Outgoing Call Stage 1,Outgoing Call Stage 2 the expression (30,20,15,43) represents anactivity where the system has tracked a total of 30 minutes of Incomingcall at sales stage 1, 20 minutes of Incoming calls at sales stage 2, 15minutes of Outgoing Calls at Sales Stage 1 and 43 minutes of OutgoingCalls for Sales Stage 2.

The innovations herein may include algorithms that uses the canonicalvector base to build a multi-dimensional decision matrix. The matrixrepresents a set of closed opportunities for which the ultimatehistorical results in term of loss or won outcomes are known. A givenmatrix will include only opportunities that the system determines to besimilar from a given perspective, which is correlated to a customizableset of data attributes. Concretely, this algorithm introduces theconcept of Context Dimension. A Context Dimension is defined byconventional SFA/CRM attributes used to describe opportunities includingbut not limited product type, customer size, opportunity size,seasonality, etc. For every attributes the algorithm defines certain aclass of measure. For example, opportunities that have an estimatedvalue that between 900K dollars and one millions dollars can beconsidered as the same class of estimated value. A Context dimension isthen expressed in term of series of attribute classes. To achieveconsistency this decision matrix will include opportunities that havethe same value for the context dimensions. In other words, the decisionsmatrix includes opportunities that have certain similar attributes. Thismulti-dimensional decision matrix can be thought of as means to give aspatial representation of the effort that has been exerted for everyopportunity of in a given set of selected opportunities. Once thesimilar opportunities are entered in the decision matrix, the algorithmdetermines proximities of loss and proximities of win. A proximity of awin is characterized by the presence of multiple “won opportunities”that are very close to each other. In contrast. A proximity of a loss ischaracterized by the presence of multiple lost opportunities that arevery close to each other. The algorithm introduces two more concepts:distance between opportunities and distances between an opportunity anda given proximity.

The distance between two opportunities is measured as the square root ofthe sum of all the square value of the difference of efforts on eachfact based dimensions. The distance between a given opportunity and agiven proximity is the mean average of the distances of the givenopportunity to all the opportunities that belong to the given proximity.Referring to FIG. 17, an exemplary algorithm may executes the followingsteps to determine if an opportunity should be removed from the pipelineor not: building the multi-dimensional matrix 1700, placing the closedopportunities in decision matrix 1702, computing all the proximities ofa win 1704, computing all the proximities of a loss 1706, adding theopportunity to the new decision matrix 1708, computing the distancebetween the new opportunity and all the proximities 1709, checking ifthe closed proximity is a proximity of a loss 1710, and if the closedproximity is classified as a proximity of a loss then it removes theopportunity from the pipeline 1712.

Additionally, the innovations herein may be achieved via implementationswith various software, hardware and/or firmware components. With regardto such other components (e.g., software modules, computing/processingcomponents, etc.) and/or computer-readable media associated with orembodying the present inventions, for example, aspects of theinnovations herein may be implemented consistent with numerous generalpurpose or special purpose computing configurations. Various exemplarycomputing systems, environments, and/or configurations that may enableor be suitable for use with the innovations herein may include, but arenot limited to: various software or other components within or embodiedon smart phones or other PDA devices or personal computing components,servers or server computing devices such as routing/connectivitycomponents, hand-held or laptop devices, multiprocessor systems,microprocessor-based systems, set top boxes, consumer electronicdevices, network PCs, other existing computer platforms, distributedcomputing environments that include one or more of the above systems ordevices, etc.

In some instances, aspects of the innovations herein may be achieved vialogic and/or logic instructions including program modules, executed inassociation with the circuitry, for example. In general, program modulesmay include routines, programs, objects, components, data structures,etc. that perform particular tasks or implement particular instructionsherein. The inventions may also be practiced in the context ofdistributed circuit settings where circuitry is connected viacommunication buses, circuitry or links. In distributed settings,control/instructions may occur from both local and remote computerstorage media including memory storage devices.

Innovative software, circuitry and components herein may also includeand/or utilize one or more type of computer readable media. Computerreadable media can be any available media that is resident on,associable with, or can be accessed by such circuits and/or computingcomponents. By way of example, and not limitation, computer readablemedia may comprise computer storage media and communication media.Computer storage media includes volatile and nonvolatile, removable andnon-removable media implemented in any method or technology for storageof information such as computer readable instructions, data structures,program modules or other data. Computer storage media includes, but isnot limited to, RAM, ROM, EEPROM, flash memory or other memorytechnology, CD-ROM, digital versatile disks (DVD) or other opticalstorage, magnetic tape, magnetic disk storage or other magnetic storagedevices, or any other medium which can be used to store the desiredinformation and can accessed by computing component. Communication mediamay comprise computer readable instructions, data structures, programmodules or other data embodying the functionality herein. Further,communication media may include wired media such as a wired network ordirect-wired connection, and wireless media such as acoustic, RF,infrared and other wireless media. Combinations of the any of the aboveare also included within the scope of computer readable media.

In the present description, the terms component, module, device, etc.may refer to any type of logical or functional circuits, blocks and/orprocesses that may be implemented in a variety of ways. For example, thefunctions of various circuits and/or blocks can be combined with oneanother into any other number of modules. Each module may even beimplemented as a software program stored on a tangible memory (e.g.,random access memory, read only memory, CD-ROM memory, hard disk drive)to be read by a central processing unit to implement the functions ofthe innovations herein. Or, the modules can comprise programminginstructions transmitted to a general purpose computer or toprocessing/graphics hardware. Also, the modules can be implemented ashardware logic circuitry implementing the functions encompassed by theinnovations herein. Finally, the modules can be implemented usingspecial purpose instructions (SIMD instructions), field programmablelogic arrays or any mix thereof which provides the desired levelperformance and cost.

As disclosed herein, features consistent with the present inventions maybe implemented via computer-hardware, software and/or firmware. Forexample, the systems and methods disclosed herein may be embodied invarious forms including, for example, a data processor, such as acomputer that also includes a database, digital electronic circuitry,firmware, software, or in combinations of them. Further, while some ofthe disclosed implementations describe specific hardware components,systems and methods consistent with the innovations herein may beimplemented with any combination of hardware, software and/or firmware.Moreover, the above-noted features and other aspects and principles ofthe innovations herein may be implemented in various environments. Suchenvironments and related applications may be specially constructed forperforming the various routines, processes and/or operations accordingto the invention or they may include a general-purpose computer orcomputing platform selectively activated or reconfigured by code toprovide the necessary functionality. The processes disclosed herein arenot inherently related to any particular computer, network,architecture, environment, or other apparatus, and may be implemented bya suitable combination of hardware, software, and/or firmware. Forexample, various general-purpose machines may be used with programswritten in accordance with teachings of the invention, or it may be moreconvenient to construct a specialized apparatus or system to perform therequired methods and techniques.

Aspects of the method and system described herein, such as the logic,may be implemented as functionality programmed into any of a variety ofcode structures or circuitry, including programmable logic devices(“PLDs”), such as field programmable gate arrays (“FPGAs”), programmablearray logic (“PAL”) devices, electrically programmable logic and memorydevices and standard cell-based devices, as well as application specificintegrated circuits. Some other possibilities for implementing aspectsinclude: memory devices, microcontrollers with memory (such as EEPROM),embedded microprocessors, firmware, software, etc. Furthermore, aspectsmay be embodied in microprocessors having software-based circuitemulation, discrete logic (sequential and combinatorial), customdevices, fuzzy (neural) logic, quantum devices, and hybrids of any ofthe above device types. The underlying device technologies may beprovided in a variety of component types, e.g., metal-oxidesemiconductor field-effect transistor (“MOSFET”) technologies likecomplementary metal-oxide semiconductor (“CMOS”), bipolar technologieslike emitter-coupled logic (“ECL”), polymer technologies (e.g.,silicon-conjugated polymer and metal-conjugated polymer-metalstructures), mixed analog and digital, and so on.

It should also be noted that the various logic and/or functionsdisclosed herein may be enabled using any number of combinations ofhardware, firmware, and/or as data and/or instructions embodied invarious machine-readable or computer-readable media, in terms of theirbehavioral, register transfer, logic component, and/or othercharacteristics. Computer-readable media in which such formatted dataand/or instructions may be embodied include, but are not limited to,non-volatile storage media in various forms (e.g., optical, magnetic orsemiconductor storage media), though do not encompass transitory media.

Unless the context clearly requires otherwise, throughout thedescription and the claims, the words “comprise,” “comprising,” and thelike are to be construed in an inclusive sense as opposed to anexclusive or exhaustive sense; that is to say, in a sense of “including,but not limited to.” Words using the singular or plural number alsoinclude the plural or singular number respectively. Additionally, thewords “herein,” “hereunder,” “above,” “below,” and words of similarimport refer to this application as a whole and not to any particularportions of this application. When the word “or” is used in reference toa list of two or more items, that word covers all of the followinginterpretations of the word: any of the items in the list, all of theitems in the list and any combination of the items in the list.

Although certain presently preferred implementations of the inventionhave been specifically described herein, it will be apparent to thoseskilled in the art to which the invention pertains that variations andmodifications of the various implementations shown and described hereinmay be made without departing from the spirit and scope of the presentinventions. Accordingly, it is intended that the invention be limitedonly to the extent required by the applicable rules of law.

1. A method of performing an event data facilitation, the methodcomprising: aggregating event data of a user on a server from aplurality of data streams; determining the event data requiring userinput; and transmitting notification to a user device to provide theuser input for the event data. 2.-3. (canceled)
 4. The method of claim1, wherein the event data is received from a plurality of networksincluding voice and electronic data communications together withgeo-location data.
 5. The method of claim 1, wherein the event dataincludes communication information including origination, destinationand time duration information.
 6. The method of claim 1, wherein theevent data includes a call event including incoming, outgoing, declinedand missed call events, name number, date, duration, call type and useridentification.
 7. The method of claim 1, wherein the event dataincludes geo-location including time, duration, speed, and accuracy ofgeographic coordinates.
 8. The method of claim 1, wherein the event dataincludes geo-location from a Wifi network, cellular network, and GlobalPositioning System (GPS).
 9. The method of claim 1, further comprising:providing user interface functionality including a selection, whereinthe event data may be classified as work-related and non-work-related.10. The method of claim 1, further comprising: providing user interfacefunctionality including a selection, wherein the event data is furtherclassified into sub-categories within the work-related and thenon-work-related classifications.
 11. The method of claim 1, furthercomprising: providing user interface functionality including aselection, wherein the event data is further classified as one ofpersonal, internal social, sales activity, business social, internalsales, internal management and information technology and logistics. 12.The method of claim 1, wherein the event data aggregated over a shortperiod of time is grouped into one event data.
 13. The method of claim1, further comprising: determining a time elapsed between occurrence ofthe event data and classification of the event data by the user.
 14. Themethod of claim 1, further comprising: providing user interfacefunctionality including a selection; and displaying the event datarequiring user input along with auto-populated fields obtained from theplurality of data streams.
 15. The method of claim 1, furthercomprising: providing user interface functionality including aselection, wherein the user input classifies the event data. 16.-94.(canceled)
 95. A method for processing information regarding dataevents, the method comprising: cross-referencing the personal event datastream with the user declared activities in a sales force managementsystem to identify discrepancies, wherein the discrepancies includesfactual discrepancies or missing data entries; and processinginformation regarding automated data verification and/or enforcing useradoption, including: determining timely compliance with required inputof the user to declare activities and perform follow-up data entry inthe sales force management system; and providing notification regardingthe discrepancies, wherein the notification includes one or both of: anautomated warning based on the user's failure to provide the requesteddata-entry regarding the event data; and/or an opportunity to enter themissing data or remedy the factual discrepancy.
 96. The method of claim95, further comprising sending an alert to management based either onthe user's non-compliance in providing the required input or on theuser's failure to remedy the factual discrepancy.
 97. The method ofclaim 95, wherein the personal event data stream includes an identifierand geo-location data from a third party system and a user device, orphone calls or text messages or emails.
 98. The method of claim 95,further comprising: identifying inaccurate user input based on thepersonal event data stream and the user input.
 99. The method of claim95, further comprising: wherein the automated warnings fornon-compliance in providing the required input is based on exceeding anelapsed time threshold.
 100. The method of claim 95, further comprising:generating historical reports of conflicts between the personal eventdata stream and the user input.
 101. The method of claim 95, furthercomprising: generating a report based on an amount of time elapsed untiluser compliance with the follow-up data entry.